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The basic approach of transmitting an intermediate, device independent 
language which is translated into specific device codes at the 
receiving host is sound. It appears to be the only approach that will 
allow thought to be centered on picture descriptions. Ames Research 
Center has adopted this approach in tying its graphic facilities, of 
various types, and on various computers together. At present, we are 
in the design phase and expect our package to be running in about six 
months. The main objections to the structure as it now exists, is that 
it takes no cognizance of the many features available on graphics 
devices. Since these features will always be changing with new 
devices, a set of option or mode primitives should be defined which 
are logically separate from the drawing primitives provided in RFC 86. 
The mode primitives will act upon the drawing primitives to modify 
their actions. The scope of a mode primitive extends until a new mode 
primitive resets an option. The use of mode primitives will allow the 
network standard stream interpreter to treat them as null operations 
if the features are missing at a particular host, or to perform more 
detailed interpretation of the following data stream to achieve 
results. The drawing primitives may also then keep a standard format 
which need not be changed to incorporate new features. 


Overall modes which primitives could control would be intensity 
levels, or color selections for objects, in addition blinking of 
objects should be provided. For vectors, the additional facility for 
drawing dashed lines is necessary. 


Character strings require another set of specification. The convention 
for the beam is usually that it is in the center of the rectangular 
area defining a character’s boundaries. The beam position is usually 
undefined at the finish of drawing a character string. A strong 
exception is taken to the exclusion of form control characters from 
strings. If included in the character string, they could provide for 
shifting from upper to lower case, subscripting, superscripting, and 
underscoring, as well as tab and other "carriage" motion functions. 
The appropriate characters could be extracted at interpretation time 
to provide the necessary information to display more complex strings. 
To allow the facility for generating ALGOL-like delimiters, such as 
"then", a convention for canonical character string should be adopted. 
I believe the Multics conventions described in reference 1 will 
suffice. 


Additional options for character strings should include a size 
specification and an orientation selection. As many devices, have 
hardware character generators that are fixed, some of these options 
may not be desirable to implement as subroutines. 


Another area that should be looked at further is the additional 
symbols available which are not specified in ASCII. Some means of 
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defining them should be provided within the argument string itself, 
again Multics has allowed the specification of arbitrary characters by 
entering their octal equivalents. The convention should use a control 
character code followed by a 16-bit list name which specifies the 
sub-list defining the character. The other alternative is to allow 
8-bit characters and allow the interpreter to choose a sub-list if the 
character is not realizable with a hardware generator. 


The special form control characters to be used are: 


a. BS - backspace 

b. LF - for new line 

c. SO/S1 - shift case 

d. DC2 - superscript following characters 

e. DC4 - subscript following characters 

fo -DC3 - special non-ASCII character follows 

g. Tab — position to next tab. May be predefined or specified. 


Another construct should be added to those proposed in RFC 86. This is 
the display list pointer (NGDLP). It will have as a value the next 
drawing primitive to be executed. The value is a displacement from the 
head of a list. With no mode setting primitives, this value is one to 
one with the drawing primitives transmitted in the NGDS. The NGDLP is 
needed for consistency for execution of the nested list structure. 
Whenever an execute list primitive is encountered, the current value 
of the NGDLP is saved along with the list name and current origin 
value. When execution of a list is finished, the last values saved are 
restored. 


An include list primitive would allow the treatment of a sub-list to 
be equivalent to a macro instead of a subroutine. This would be 
necessary to avoid changes to all sub-pictures on the screen due to 
the manipulation of a sub-list. The include primitive should have as 
parameters such specifications as size, intensity, orientation, 
blinking, etc. After a sub-list has been included in another list, it 
is no longer distinguished as a separate entity. 


To cut down on the volume of data being transferred, other commands to 
be parsed by the stream interpreter should be added. These would allow 
the manipulation of a list by the receiving host without a 
retransmission. The types of manipulations would include rescaling 
the coordinates for shrinking or zooming, translation of the origin, 
or rotation. Other manipulations to provide for displaying or not 
displaying a list, or enabling of disabling light pen detections would 
be desirable. 


The problem of interaction with the displayed picture has yet to be 
addressed, so this will be an attempt to elicit some more discussion 
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in this area. The use of a keyboard or function keys poses no problem 
in that both can be handled as a standard message from the graphics 
terminal. The use of devices that interact with the picture or the 
screen such as light pens, mice, joysticks, or tablets presents a 
different and more complex problem. This problem is the standard one 
of making an association between the point selected and some 
meaningful entity such as a list or a primitive. This association 
should be made at the receiving host since the NGDS has been changed 
in unknown ways. 


To allow the transmitting host to identify the object pointed at, the 
stack of suspended lists and the current value of the NGDLP will 
qualify the object to any level in a hierarchical structure. In 
addition, normalized x,y coordinates should be returned, as well as a 
character displacement if a string was pointed at. This structure will 
serve a light pen device very well since the light pen mechanism 
allows the determination of the currently executing primitive. Other 
devices interact with the picture in an asynchronous fashion and the 
association of an x,y pair to a structure is a more difficult problem. 
This may require that the host generating the graphic data stream be 
responsible for making that association. A further complication arises 
when it is desired to use a light pen in an area where no beam motion 
occurs, then some directive to periodically sweep the screen and 
"find" the pen must be provided. This might be a sub-list which is 
executed periodically for this function. 


[ This RFC was put into machine readable form for entry ] 
[ into the online RFC archives by Jerry Tenenbaum 4/97 ] 
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